Add conformsTo argument to member macro expansion operation #2004
Conversation
|
@swift-ci please test |
DougGregor
force-pushed
the
member-macro-conformances
branch
from
a0a6ce8 to
6ff4a07
Compare
| @@ -236,6 +236,7 @@ public func expandAttachedMacroWithoutCollapsing<Context: MacroExpansionContext> | |||
| let members = try attachedMacro.expansion( | |||
| of: attributeNode, | |||
| providingMembersOf: declGroup, | |||
| missingConformancesTo: conformanceList?.map(\.type) ?? [], | |||
There was a problem hiding this comment.
Why is this parameter called missingConformancesTo:? AFAICT you are passing in the existing conformances, not some list of missing conformances.
There was a problem hiding this comment.
I'm struggling mightily to name this. Let's discussion naming over at https://forums.swift.org/t/pitch-member-macros-that-know-what-conformances-are-missing/66590
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
DougGregor
force-pushed
the
member-macro-conformances
branch
from
8d1c176 to
f1eaeec
Compare
|
@swift-ci please test |
DougGregor
changed the title
|
@swift-ci please clean test |
DougGregor
force-pushed
the
member-macro-conformances
branch
from
cf38182 to
d3a820a
Compare
|
@swift-ci please test |
… operation Stage in an entrypoint for member macros that allows them to learn about which conformances that they've asked about are "missing", meaning that they are not present on the type (ignoring those that would be generated by an extension macro). This information is equivalent to the information provided to extension macros, although the member macro itself cannot create the conformance.
DougGregor
force-pushed
the
member-macro-conformances
branch
from
d3a820a to
5ff03e2
Compare
|
@swift-ci please test |
DougGregor
changed the title
|
@swift-ci please test Windows |
| public extension MemberMacro { | ||
| /// Default implementation supplies no conformances. | ||
| static func expansion( | ||
| of node: AttributeSyntax, | ||
| providingMembersOf declaration: some DeclGroupSyntax, | ||
| in context: some MacroExpansionContext | ||
| ) throws -> [DeclSyntax] { | ||
| return try expansion(of: node, providingMembersOf: declaration, conformingTo: [], in: context) | ||
| } | ||
|
|
||
| /// Default implementation that ignores the unhandled conformances. | ||
| static func expansion( | ||
| of node: AttributeSyntax, | ||
| providingMembersOf declaration: some DeclGroupSyntax, | ||
| conformingTo protocols: [TypeSyntax], | ||
| in context: some MacroExpansionContext | ||
| ) throws -> [DeclSyntax] { | ||
| return try expansion(of: node, providingMembersOf: declaration, in: context) | ||
| } |
There was a problem hiding this comment.
I don’t think adding default implementations that forward in both directions is a good way. If I write the following,
public struct X: MemberMacro {}it compiles just fine without any error that I’m missing any protocol requirement and the call to the expansion function will just infinitely recurse.
There was a problem hiding this comment.
I can stage out one of them, but for now I want forward/backward compatibility.
I can do this in a follow-up |
Stage in an entrypoint for member macros that allows them to learn about which conformances that they've asked about are "missing", meaning that they are not present on the type (ignoring those that would be generated by an extension macro). This information is equivalent to the information provided to extension macros, although the member macro itself cannot create the conformance.